索引量掉到47那天，才发现爬虫从不滚动页面

一家做实验室耗材的公司，官网改版上线第十一周，运营在站长平台后台盯着索引量那条曲线：站内 214 个产品详情页，被收录的数量从 189 掉到 47。更蹊跷的是搜索结果里那几条摘要，显示的全是页脚的公司地址和备案号，一个字都没提到产品。

销售拿手机点开同一个页面，参数表、应用场景、技术指标三块内容整整齐齐，什么毛病都看不出来。前端在自己电脑上又刷了七八遍，页面完好。直到有人在站长平台跑了一次抓取诊断，把渲染之后的源码拉出来比对，才看清那三块内容对应的位置上只剩三个空容器和一个转圈的占位图标。

第一层：分数是当天能看到的，收录量不是

改版时前端接了一项硬指标，把移动端的 PageSpeed 分数从 61 提到 90 以上。最见效的一招是让首屏之外的模块统统不参与首次渲染，于是所有非首屏区块被改成滚动到视口再注入——用 IntersectionObserver 监听占位容器，进入视口时请求一次接口，拿回 HTML 片段再塞进去。分数当天就冲到 94。网页制作里，延后加载几乎是不需要讨论的默认项，谁也不会在评审会上单独把它拎出来说一句。

问题出在爬虫不滚动。抓取工具打开页面时视口是一个固定高度，常见值在 800 到 1080 像素之间，它渲染完就取源码走人，从头到尾没有「滚动」这个动作。观察器一次都不会触发，那些接口一次都不会被调用。人眼看到的和机器读到的，从第二屏开始就是两份完全不同的东西。

再往下追一层，是验收清单的问题。这次改版的验收项一共七条，其中三条讲速度：移动端分数、首屏时间、总请求数。没有任何一条要求检查渲染完成之后的 HTML 里究竟还剩什么。所有测试都是人拿着鼠标从上滚到下，看内容一块块浮出来，然后打勾。

这不能怪谁偷懒。分数是当天就能截图汇报的数字，收录量的变化要等三到八周才会在曲线上显形。网页制作的验收会一般开在上线前一周，那个时间点后者根本没有数据可看。两个指标不在同一个时间尺度上，验收会自然只认得出前者。

最底下那层：延后字节和延后存在，被写成了同一个词

图片延后加载，延后的是字节。标签在 HTML 里，alt 在，尺寸在，抓取的那一刻它是存在的，只是像素还没下载完。整块内容延后注入，延后的是存在本身：页面被读取的那一刻，那些文字压根不在文档里，等同于没写过。前者是加载策略，后者已经是内容策略——可它们在代码里都叫 lazy，在需求文档里都写作「懒加载优化」四个字，于是被一起勾选了。

先把三类东西分开，边界自己就清楚了

第一类可以放心延后：图片、视频、地图 iframe、在线客服和分享类的第三方脚本。它们延后的是流量，不改变文档结构。第二类一个字都不能延后：产品参数、技术指标、正文段落、常见问题的答案、面包屑导航，以及页面上任何构成主题的文字。第三类是灰色地带，也就是选项卡和折叠面板里的内容，判断办法只有一个——这段文字你希不希望有人搜到。希望，就必须写进初始 HTML，再用样式收起来；不希望，才允许点击之后现取。这条线在网页制作动工之前画在原型图上，比上线三个月后回头改省事得多。

原生属性的三条边界

首屏图片不能加 lazy。给最大的那张主视觉加上延后属性，浏览器要等布局算完才肯发请求，实测 LCP 会多出 300 到 700 毫秒，恰好把别处省下来的时间抵消掉。首屏那一两张图应该反着做，把 fetchpriority 设成 high，条件允许再补一条 preload。

每一张延后加载的图都必须写死宽高属性或者给出宽高比。不写，占位高度是 0，图片下载完成的瞬间页面往下弹一截，CLS 从 0.02 蹿到 0.25 以上，手机上尤其难看。这一项验收时最容易漏，因为办公室网络快，弹那一下眨眼就过去了。

能用原生属性就别自己写脚本实现。手写的 data-src 方案有两个隐患：JS 一旦报错，整页图片全是空白；src 属性长期为空，图片搜索什么也抓不到，产品图原本带来的那部分流量会一起消失，而这类损失在网页制作的报价单上从来不体现成本。

触发距离设成 0 是另一种毛病

不少现成组件的 rootMargin 默认值是 0，意思是元素边缘刚碰到视口下沿才开始下载。用户滚到那个位置，看到的是灰块，4G 环境下一张 200KB 的图要 400 到 800 毫秒才填上，一路往下滚就是一路打补丁。合理的提前量是 200 到 400 像素，图片密集的列表页可以放宽到 600。这不过是改一个数字的事，但很少有人改，因为它藏在默认配置里，而默认配置从来不进评审。

无限滚动要留一条不靠脚本的路

列表页做成滚动加载更多，第一屏之后的产品对爬虫就不存在了。开头那家公司丢掉的产品页里，相当一部分是这么没的——列表页只输出前 12 条，剩下的靠滚动追加，站内没有任何一个地方能靠链接走到第 13 条。补救办法是保留真实的分页地址，例如 /products/2/ 这样的路径，用真实链接输出在 HTML 里，视觉上可以做小、挪到页脚，但必须是能点也能被读到的链接。检验方式很朴素：把浏览器的脚本全禁掉，看你还能不能翻到第五页。

三道自查，五分钟跑完

第一道，用 curl 把页面原始 HTML 拉下来存成文本，搜一段产品参数里的原话。搜得到，说明内容是服务端直接输出的，这一页安全。搜不到，进第二道。

第二道，在站长平台的 URL 检查或者抓取诊断里查看渲染之后的源码。如果这里依然搜不到那句话，基本可以断定是延后注入把内容吃掉了。

第三道，在浏览器里把 JavaScript 禁用掉再打开这一页。这一步最直观，截图发到群里，比讲十分钟原理管用。还可以补一个动作：用无头浏览器把视口高度设成 600 像素，只截一屏、不滚动，截出来的画面就很接近爬虫看到的样子。

数量本身也是一条边界

单页挂 80 个以上的观察目标，回调开销在中低端安卓机上会拖出能感觉到的滚动掉帧，这时候延后加载反而是负收益，产品图超过 40 张就该改成分页或者分组。反过来，在线客服、统计、分享按钮这些第三方脚本延到用户第一次滚动或点击之后再加载，通常能省下 300 到 600KB，而且这部分延后对搜索完全无害，因为它们本来就不产生内容。真想提分数，先动这一块，网页制作里性价比最高的优化往往都落在这些与内容无关的资源上。

把它变成一道是非题

在网页制作的交付清单里加一行，不打分，只填是或否：禁用 JavaScript 之后，本页的主体文字是否仍然存在。填否的页面不许上线。这一行的价值在于它没有解释空间，不像「首屏加载正常」那种描述，怎么测都能说自己通过了。

判断一个延后加载方案有没有越界，其实不必读代码。把页面用 curl 拉下来存成一个 txt，打开搜一下你最希望客户搜到的那句话，可能是一个型号，也可能是一项技术指标。搜得到，它还只是加载策略；搜不到，它已经替你做完了内容上的取舍，而这个取舍当初没有在任何一次会上被提出来讨论过。